As remote access of computer systems and applications grows in popularity, the number and variety of transactions which are accessed remotely over public networks such as the Internet has increased dramatically. This popularity has underlined a need for security; in particular: how to ensure that people who are remotely accessing an application are who they claim they are, how to ensure that transactions being conducted remotely are initiated by legitimate individuals, and how to ensure that transaction data has not been altered before being received at an application server.
In the past, application providers have relied on static passwords to provide the security for remote applications. In recent years it has become evident that static passwords are not sufficient and that more advanced security technology is required.
One way of solving the security problems associated with remote access to computer systems and applications over public networks is provided by a Public Key Infrastructure (PKI). Using a Public Key Infrastructure one associates a public-private key pair with each user. The key pair is associated with a certificate (issued by a trustworthy Certificate Authority) that binds that public-private key pair to a specific user. By means of asymmetric cryptography this public-private key pair can be used to authenticate the user, sign transactions, and set-up encrypted communications.
To guarantee an adequate level of security it is mandatory that each user's private key remains secret and can only be accessed to create a signature or to decrypt a message by the legitimate user associated with that key. It is common to rely on a smart card or a dedicated Universal Serial Bus (USB) device (sometimes referred to as a USB key or a USB token) to store the public-private key pair and the certificate and to carry out the cryptographic calculations involving the private key.
There are some disadvantages associated with PKI and the smart cards carrying the PKI keys and certificates:    1. Building a Public Key Infrastructure is generally complicated and therefore expensive when compared to competing security technologies.    2. PKI is inherently limited to environments and applications where there is a digital connection between clients and servers, because PKI cryptograms and signatures are bulky and not easily transformed into human-readable form. In other words it is unsuitable for telephone banking or other delivery channels where it is not possible to provide a digital connection between the container of the PKI certificate and private key on the one hand and an application server on the other hand.    3. PKI smart cards and USB tokens do not have a built-in power supply or a user interface. PKI smart cards and USB tokens therefore rely on the presence of an interfacing system that provides electrical power to the card, that is capable of digitally exchanging data with the card, and that is capable of interacting with the user (e.g. capturing the card's PIN and presenting the data that should be signed). USB tokens are usually plugged into a built-in USB port of a PC, where the USB port supplies power to the USB token and the human interface devices connected to the PC provide the user interaction capabilities (connected USB token model). PKI smart cards are usually operated by means of a PC equipped with a simple smart card reader, where the reader only supplies power to the smart card and enables communication between an application on the PC and the inserted smart card, and whereby the human interface devices connected to the PC provide the user interaction capabilities. Such a reader, which has no trustworthy user interface of its own, is often referred to as transparent card reader. These typical usage models reduce the mobility of the user, as most PCs are not pre-equipped with smart card readers, and ad-hoc installation of drivers for the readers of USB tokens proves too cumbersome. It also presents a security problem: all user interaction (such as approving a signature or capturing the card's PIN) is done on the inherently insecure PC.
Another approach consists of adding software applications offering security functions to general purpose devices such as a user's PC, or mobile device (e.g., mobile phone or PDA). The main problem associated with this approach is that general purpose devices have an inherently open architecture which makes them susceptible to all kinds of malicious software such as viruses and Trojans that could present fake messages to the user or capture whatever the user enters on the keypad or read in memory sensitive data associated with a security application or alter data before they are being signed. Therefore general purpose devices can not be considered to have a trustworthy user interface and don't have secure means to store secrets such as PIN values and cryptographic keys. Furthermore, known solutions for mobile devices rely on wireless subscriber networks for the reception and/or transmission of transaction data. Such networks have inherent security and end point authentication mechanisms in place, which cannot be assured to be present when the Internet is used for all transmissions.
An alternative technology for authentication and transaction signature capabilities, which avoids the security issues of solutions based on general purpose devices and the security, installation and interconnection problems of PKI smart cards and USB tokens, is offered by ‘strong authentication token devices’. Typical examples of strong authentication tokens are the products of the DIGIPASS® line, commercialized by Vasco Data Security Inc. (see the website http://www.vasco.com). A strong authentication token is an autonomous battery-powered device, dedicated to providing authentication and transaction signature functions, usually pocket-size, with its own display and keypad. In some cases the keypad is reduced to a single button or even completely omitted, in other cases the keypad can be a full keyboard. The display and keypad of a typical strong authentication token are non-removable and not user-serviceable, fully controlled by the token, and immune for interference by malicious software on a host computer. Therefore strong authentication tokens are considered to have a trustworthy user interface in contrast to e.g. PCs where there is always the possibility that malicious software such as a virus or a Trojan presents fake messages to the user, or captures whatever the user enters on the keypad, or reads in memory sensitive data associated with a security application or alters data before they are being signed. The main purpose of a strong authentication token is to generate dynamic security values which are usually referred to as ‘One-Time Passwords’ (OTPs). Typically these OTPs are generated by cryptographically combining a secret that is shared between the token and a verification server with a dynamic value such as a time value, a counter value or a server challenge that is provided to the token, or a combination of these. Same strong authentication tokens can also use data (such as transaction data) that have been provided to the token as dynamic value or in combination with any of the dynamic values mentioned above to generate a security value. In these cases the resulting security value is meant to indicate the user's approval of the data and the security value is usually referred to as an electronic signature or Message Authentication Code (MAC). Some strong authentication tokens consist of a device with a display and a keypad that is capable of communicating with an inserted smart card whereby the generation of the OTPs or MAOs is partly done by the device itself and partly by the inserted smart card.
A typical way to provide data to a strong authentication token is by letting the user enter the data manually on the token's keypad. When the amount of data that has to be entered in this way exceeds a few dozen characters, the process is often perceived by users as too cumbersome. To relieve the user, solutions have been devised whereby the input of data doesn't require the manual entry of said data by the user on the token's keypad. One example are solutions whereby the token comprises receiving means to receive data sent over an out-of-band channel such as for example a radio network or mobile telephony network (U.S. Pat. No. 5,668,876 Sep. 16, 1997). The disadvantage of such out-of-band solutions is the extra complexity and cost associated with supporting the technology of said out-of-band channel, and the dependence on the availability and the cost of usage of said out-of-band channel. Another solution consists of tokens that allow for data input by means of an optical interface, whereby the user holds the token close to a computer screen that displays a varying optical pattern. Examples of such optical tokens are Digipass 700 and Digipass 300 offered by Vasco Data Security, and the tokens described in EP 1211841 Jun. 5, 2002, EP 1788509 May 23, 2007, U.S. Pat. No. 5,136,644 Aug. 4, 1992.
The most common and practical mechanism to transfer the generated OTPs or MAOs to the servers or applications to be protected is by manual copying of said security values as presented by the token into the computer and transmitting them to the server or application using the same in-band channel as the other interaction between the user and the computer system or application being protected. Other solutions exist whereby security values are transferred using another out-of-band channel such as for example a radio network or mobile telephony network. The disadvantage of such out-of-band solutions is the extra complexity and cost associated with supporting the technology and usage of said out-of-band channel.
A general problem of tokens with an optical data input interface is that relatively expensive components are required to build an interface that can take in data at a high data rate. This is a consequence of the requirement to work reliably in a very broad range of computer screen qualities and environmental lighting conditions, combined with the relatively low refresh rates of typical computer screens. A more cost-effective alternative is to use a low-speed optical interface, limiting the transaction data that are effectively submitted to the token to a small number of values. For example, in the case of a money transfer the transaction data that is effectively being signed is often limited to just the amount value and the destination account number. These values are presented to the token without any contextual information regarding the type of transaction and the exact meaning of the transaction values, as the transaction type and the actual meaning of the transaction values is assumed to be known implicitly.
This lack of context information, in combination with the fact that the same tokens are sometimes used to secure very different types of applications and transactions, could be exploited in a specific kind of social engineering attack whereby the attackers convince legitimate users to sign with their token a sequence of values that the attackers present to the users as corresponding to an apparently legitimate and innocent transaction, after which the attackers submit in a completely different transaction or application type the same sequence of values and the signature fraudulently obtained from the legitimate users. For example, to protect money transfers, a bank might require users to sign with their token the values of the amount to be transferred and the account where the money should be sent to. An attacker who wants to fraudulently transfer money from victims' accounts to the attacker's account could circumvent this signature protection mechanism by tricking victims into signing with their token two innocent looking values that the attacker presents to them in such way that the victims don't associate the two values with an amount and an account number for a money transfer. The attacker might for example invite the victims to participate in a kind of lottery where they supposedly can win some exotic trip. The only thing they need to do to have a chance of winning is to generate and submit a lucky number by signing a date of departure e.g. Dec. 20, 2008 represented as, 12-20-08, and a participant reference number e.g. 1234-5678-9002. The victims end up signing the values ‘122008’ and ‘123456789002’ where after the attacker submits to the bank the fraudulent money transfer of 1220.08 dollar to the account 123-4567890-02. The bank accepts this transaction since the attacker can submit a valid token signature oh the values ‘122008’ and ‘123456789002’ corresponding to the fraudulent transaction.
Another problem with the current generation of strong authentication tokens is that they will generate OTPs on the simple request of the user. This makes it possible for attackers to lure unsuspecting users by means of false pretexts into generating and handing over valid OTPs which can then be used by the attackers to successfully authenticate to an on-line application.